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THE CSM TESTBED SOFTWARE SYSTEM: A Development Environment for Struc- 
tural Analysis Methods on the NAS CRAY-2 

INTRODUCTION 

The Computational Structural Mechanics (CSM) Activity at the NASA Langley Research 
Center is developing structural analysis methods that exploit modern computers (ref. 1). 
To facilitate that research effort, a development environment has been constructed to 
insulate the researcher from the many compute) operating systems of a widely distributed 
computer network. This paper describes that environment and its extension to include the 
supercomputer resources of the Numerical Aerodynamic Simulator (NAS) CRAY-2 rw , at 
the NASA Ames Research Center. 

The field of computational structural analysis is dominated by two types of computer 
programs. One type is the huge, 2000 subroutine (ref. 2), general purpose program that 
is the result of over a hundred man-years of effort spanning over a decade; the other 
type is the relatively small code resulting from an academic or research environment that 
represents a one- to two-year effort for a specific research application. This dichotomy has 
resulted in long delays in making research technology available for the critical structures 
problems that NASA faces. To address the problem of accelerating the introduction of 
successful research technology into large-scale applications programs, a modular, public- 
domain, machine independent, architecturally simple, software development environment, 
denoted the CSM Testbed, is being constructed. 

A development environment which insulates both the structural analyst using the Testbed 
and the methods developer writing enhancements for it is important in a distributed en- 
vironment. Distributed environments are made up of stand-alone computers of different 
sizes, architectures, and vendors, with a common network protocol offering the user easy file 
transfer and remote login functions. Structural analysts require the diverse computer ca- 
pabilities offered by a distributed environment (workstation-mainframe-supercomputer), 
but cannot afford the “overhead” of learning the operating system commands for each 
system they use. Methods developers have a similar problem, but at a lower level. They 
cannot afford the “overhead” of learning a new set of system calls for each computer on 
which they wish to implement their application code. The CSM Testbed addresses these 
problems. 
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The CSM Testbed development environment was ported to the CRAY-2 to provide a high 
end computational capability for structural analysis research. Earlier Testbed development 
efforts were directed toward mainframes and minicomputers even though the complexity 
of the structures that were being analyzed was growing. It was only through the struc- 
tural analyses required during the space shuttle Challenger accident investigation and 
subsequent recertification program (ref. 3) that the magnitude of the computational task 
required for large-scale structural analyses was fully appreciated. After that experience, it 
was clear that if this research Testbed was to be used to learn how to solve problems of 
critical interest to NASA, the Testbed would have to be available on a true supercomputer. 
To that end, the CSM Testbed was ported to the NAS CRAY-2 at the Ames Research 
Center. This paper describes the implementation experiences, the resulting capability, and 
the future directions for the Testbed on supercomputers. 

PROGRAM STRUCTURE 

The CSM Testbed program is an example of a modern software architecture designed to 
support development of engineering analysis methods as well as to perform engineering 
analyses. Its organization is illustrated in figure 1. The inner circle in figure 1, the 
computer operating system, is provided by the computer vendor and is different for each 
vendor. The outer ring in the figure, the development environment, insulates both the 
user and the methods developer from those differences by providing a consistent interface. 

The CSM Testbed is written primarily in Fortran and is organized as a single executable 
file, called a macroprocessor. The macroprocessor calls structural applications modules 
(also known as processors) that have been incorporated as subroutines. Applications mod- 
ules are installed into the macroprocessor as they become accepted in the structural anal- 
ysis community and are of a general interest to other researchers. The macroprocessor and 
applications modules interface with the operating system for their command input and 
data management functions through a set of “architectural utilities” that originated in a 
software system called NICE (Network for Integrated Computational Elements) (ref. 4). 
Processors access the Testbed utilities by calling entry points implemented as Fortran-77 
functions and subroutines which are available to module developers in the Testbed object 
libraries. Applications modules do not communicate directly with each other, but instead 
communicate by exchanging named data objects in a database managed by a data manager 
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called GAL (Global Access Library). The user controls execution of applications modules 
via an interactive or batch command input stream written in a command language, called 
CLAMP (Command Language for Applied Mechanics Processors) which is processed by 
CLIP, the Command Language Interpreter Program. Command language procedures for 
performing complex analysis tasks may be developed and stored for future use. 

To facilitate the development of new methods and algorithms, a capability for indepen- 
dent executable programs to perform special functions related to a Testbed analysis is 
included. Applications may be developed independently, using the Testbed architectural 
utilities and data management capabilities, and may be invoked from within a Testbed 
command procedure or runstream; this type of program is called a Testbed external pro- 
cessor. The macroprocessor and external processors may be used within a single Testbed 
command input stream via the architectural utility, SuperCLIP (ref. 5), which performs 
the interprocessor exchange via operating system calls which are invisible to the user. This 
capability provides much of the flexibility required of the CSM Testbed as it relates to the 
development of new applications. 

For structural analysis research, both interactive 1 and batch modes of operation are required 
and both are supported in this program. Throughout the CSM Testbed development 
effort, attention has been given to the problems associated with research codes and their 
requirements for generality, while keeping a watch on overall efficiency. Efficiency affects 
the overall size and complexity of the structural problems that can be considered, and if 
current structures research problems are to be solved, efficiency must be maintained. 

The Testbed Command Language 

The Testbed command language, called CLAMP, is a generic language originally designed 
to support the NICE system and to offer program developers the means for building 
problem-oriented languages (ref. 6). It may be viewed as a stream of free-field command 
records read from an appropriate command source (the user terminal, actual files, or 
processor messages). The commands are interpreted by a “filter” utility called CLIP, whose 
function is to produce object records for consumption by its user program. The standard 
operating mode of CLIP is the processor-command mode. Commands are directly supplied 
by the user, retrieved from ordinary card-image files, or extracted from the global database, 
and submitted to the running processor. Special commands, called directives, are processed 
directly by CLIP; the processor is “out of the loop”. Transition from processor-command 
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to directive mode is automatic. Once the directive is processed, CLIP returns to processor- 
command mode. Directives are used to dynamically change run-environment parameters, 
to process advanced language constructs such as macrosymbols and command procedures, 
to implement branching and cycling, and to request services of the data manager. CLIP 
can be used in this way to provide data to a processor as well as to control the logic flow of 
the program through a single input stream. All command language directives are available 
to any processor that uses the CLIP-Processor interface entry points. 

Program execution begins with control transferred to the Testbed macroprocessor by the 
computer operating system. Within the macroprocessor an entry point requesting a read 
operation is called which begins parsing and interpreting command language directives. 
This operation continues until a complete processor command record has been read and 
processed by CLIP. That data record is then returned to the calling module to be in- 
terpreted according to the application or macroprocessor originally requesting the read 
operation. The next read operation continues the cycle until a command is encountered 
which directs the program to terminate. This process not only provides for module se- 
quence control, but also provides a powerful input data description language for preparing 
processor input. Both capabilities are incorporated through the same applications language 
environment. 

The NICE Data Manager 

The data manager within the CSM Testbed was derived from the Global Access Library 
(GAL) concept developed at the Lockheed Palo Alto Research Laboratory (ref. 7). Meth- 
ods for data management in structural analysis programs can be broken into three levels 
of complexity: file systems, file partition systems, and data base systems (ref. 8). Since 
GAL database files are subdivided or partitioned into data sets the Testbed data manager 
is classified as a file partition manager. To a processor, a GAL data library is analogous to 
a file. It must be opened, written, read, closed, and deleted explicitly. The global access 
library resides on a direct-access disk file and contains a directory structure called a table 
of contents (TOC) through which specific data sets may be addressed. Low level routines 
access the GAL library file in a word-addressable scheme as described by Felippa in ref- 
erence 9. The data management system is accessible to the user through the command 
language directives and to the running processors through the GAL-Processor interface. 

The actual I/O interface to the UNICOS™ operating system for the CRAY-2 is accom- 
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plished through a set of block I/O routines written in the C programming language. To 
provide the efficiency required to process the volume of data required for a complex struc- 
tural analysis, all usual overhead associated with Fortran has been eliminated. Listings of 
the routines used for block I/O in the Testbed are presented in Appendix A. 

The global database is made up of sets of data libraries (GALs) residing on direct-access 
disk files. Data libraries are collections of name d datasets, which are collections of dataset 
records. The data library format supported by the Testbed is called GAL/82, which can 
contain nominal datasets made up of named records. Some of the advantages to using this 
form of data library are: l) the order in which records are defined is irrelevant, 2) the data 
contained in the records may be accessed from *,he command level, and 3) the record data 
type is maintained by the manager; this simplifies context-directed display operations and 
automatic type conversion. 

SuperCLIP Implementation 

The SuperCLIP capability of the Testbed architecture performs interprocessor control, 
allowing independent programs which use the Testbed architecture facilities (CLIP and 
GAL) to be executed from within a single Testbed input stream. SuperCLIP handles the 
interprocessor CLIP state preservation and restoration so that the CLIP environment is 
maintained across independent program executions. These independent programs can be 
used in conjunction with the Testbed macroprocessor, other independent Testbed proces- 
sors, or entirely alone, as appropriate to accomplish the required task. The implementation 
of SuperCLIP is the most complex and machine dependent element of the Testbed architec- 
ture software. To date it has been implemented under VAX™ /VMS™ and the UNIX™ 
operating systems. 

The operations performed by SuperCLIP to accomplish the processor exchange are as 
follows: 

1. The name of the executable file for the n«;w processor is pushed onto a stack data 
structure called the Process Name Stack. 

2. The CLIP data structures are saved. This in done by writing the contents of the CLIP 
data structures to a file, named ZZZZZZZ, via the data manager. The structures 
include the Decoded Item Table, Macrosymbol Table, Command Source Stack, Process 
Name Stack, control characters, logical unit table, and list of active data libraries. All 
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open libraries are closed. 

3. The process switch is performed. For the VAX/VMS version, this is done via the 
LIB$RUN_PROGRAM system function. For UNIX, it is done via the EXECLP system 
function. Both functions stop the current process and start the target process. 

4. CLIP is initialized in the new processor. The new processor calls CLIP for data input; 
CLIP tests for the existence of the ZZZZZZZ file to determine if this processor is 
executing as the result of a SuperCLIP operation. If the file exists, the CLIP state is 
restored. 

5. The CLIP state is restored. The ZZZZZZZ file is read via the data manager to restore 
the CLIP data structures. Non-scratch libraries that were open in the parent processor 
are re-opened. The Command Source Stack is reconstructed so it has the same array 
of open files, and script files are restored to their original positions. The ZZZZZZZ file 
is closed with the delete option so it disappears. 

A Testbed processor terminates via a SuperCLIP function which performs many of the 
same functions described above. The first step is the only one which is different. Here 
the name of the parent processor is extracted from the Process Name Stack, which is then 
removed from the stack. If the stack is empty, a normal termination is performed. If the 
stack is not empty, the parent processor becomes the target process and steps 2-5 above 
are performed 

The only part of the SuperCLIP operation which is different for the two implementations 
is the process switch operation which requires different system function calls for the dif- 
ferent systems. In the UNIX version, any files which were opened via the Fortran OPEN 
statement must also be closed, since files are allowed to remain open across the EXECLP 
calls. 

Structural Application Modules 

The application modules are installed in the Testbed system in a macroprocessor config- 
uration. They perform functions related to a structural analysis task, including model 
definition, element interconnection analysis, system matrix assembly and factoring, static 
stress analysis, eigenvalue analysis, thermal analysis, data display, and postprocessing 
functions. Additional pre- and post-processing functions have been implemented as in- 
dependent executable programs called external processors. The initial structural analysis 
functions were implemented by interfacing processors from the SPAR structural analysis 
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system with the NICE architecture utilities (rel. 10). 

Since the initial installation, many new modules have been developed to replace or com- 
plement the original functions. A software “shell” and utilities have been developed to 
facilitate installation of new types of structural elements into the Testbed. Several ele- 
ment processors have been developed based on this shell and have been installed in the 
Testbed. Pre- and post-processing functions as well as modules implementing new solution 
algorithms have also been developed and installed. A description of the current analysis 
capability of the Testbed is presented in reference 11. 

The architecture of the Testbed supports the independent development of new software 
capabilities by structural analysis researchers and numerical methods developers via the 
SuperCLIP facility. This facility and the supporting architectural utilities allow the macro- 
processor modules and independent programs to access command language symbols and 
data library contents. 

COMPUTER ENVIRONMENT 

The CSM Testbed was originally developed on a VAX 11/785 computer using the VMS 
operating system. In order to address the new computer architectures, it became necessary 
to migrate to the UNIX environment. 

The Testbed relies heavily on the available UNIX tools to provide a common developer 
interface across the distributed environment. In addition to the UNIX tools, system in- 
dependent precompilers that support conditional compilation and text insertion complete 
the requirements for maintaining the software for the distributed environment. 

Machines 

The Testbed is currently operational on the following types of computers: VAX/VMS, 
Micro VAX™ /ULTRIX™, SUN™/UNIX, FLEX/32™/UNIX, and CRAY-2/UNICOS. 
This wide range of computer capabilities create a development environment that makes 
maximum use of computers at all levels of capability. It is possible to begin an application 
task at a small single user workstation, develop and test new algorithms using small test 
cases on a minicomputer, and apply those algorithms on large complex structures using the 
resources of a supercomputer, all under one application environment, all without modifying 
any of the Fortran code from that developed on the original workstation. 
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A single application task often spans the entire range of computers. Model development 
usually occurs on a workstation, and the final analysis is usually performed on a super- 
computer. Although the data libraries are not readable in binary form among the non- 
homogeneous computers, the Testbed has commands which allow the user to format data 
into text files on one computer, and after transferring the text files to the target computer, 
to restore the data on the target computer for further Testbed processing. These com- 
mands are typically used to transfer analysis results from the CRAY-2 to a local Micro VAX 
workstation for graphics postprocessing. 

Distributed Environment 

The CSM computers at NASA Langley are linked via the Langley local area network to the 
NASNET computer network as well as many other government and university computer 
systems. This network gives researchers the capability of developing and testing new 
methods in several different computer environments, selecting the machine characteristics 
which are appropriate for the type of analysis to be performed. 

All computers available to the NASA Langley CSM researchers are available through the 
Internet TCP /IP communication protocol. Individual computers are linked via ethernet 
within buildings at Langley Research Center. Gateways are provided between buildings 
by a Pronet-10™ token passing ring. A one megabit /second communication link using a 
Vitalink™ bridge over a terrestrial, Tl, circuit connects Langley Research Center to the 
Ames Research Center and provides the backbone for the Langley-Ames NASNET con- 
nection to the NAS CRAY-2. The resulting network has provided an effective interactive 
capability as well as high speed file transfer for CSM researchers. Supercomputer resources 
are provided directly to the individual workstation. The high speed of the long distance 
communication link gives almost transparent interactive use as well as access to files. Even 
the large data library files created by the Testbed are easily accessible under this network 
for transmission to graphics workstations for postprocessing. 

THE PROGRAM CODE 
Master Source Code 

The program code for all target versions of the Testbed is maintained in single copies of 
the source files, in a format called Assembled Master Source (AMS) form. Embedded pre- 
processing commands allow selective conditional precompilation by machine-independent 
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utility programs. An example of this form is given in Appendix B, which contains a listing 
of the main program for the Testbed macroprocessor in the AMS format. Procedures for 
extracting specific target versions of the compiler source code have been developed for all 
the systems on which the Testbed has been installed. All source code files and procedures 
are maintained with the Revision Control System on a Micro VAX computer using the 
ULTRIX operating system. 

The architecture code is made up of approximately 650 modules with about 83000 lines 
in source code and include files. The application code is made up of approximately 1300 
modules with about 95000 lines in source code and include files. Distribution of the code 
in the UNIX environment is accomplished by packaging the source code, makefiles, and 
scripts in a single file using the tape archive utility (tar); this distribution file occupies 
approximately 8 megabytes on disk. 

Machine Independent Tools 

Two utility programs, MAX and INCLUDE, which operate on the master source files were 
originally developed by Carlos Felippa at Lockheed Palo Alto Research Laboratory (ref. 
12). The MAX utility allows distribution of source code for selected target compilers, 
computers, and operating systems from a Master Source file which supports the targets. 
The INCLUDE utility allows text insertion from files named in the source code, similar to 
the “include” facility of VAX Fortran, in a machine independent manner. Both of these 
utilities have been modified from the original VAX versions to execute in a UNIX envi- 
ronment and under the UNICOS operating system on the CRAY-2 computer. The main 
program of the Testbed macroprocessor is presented in Appendix B along with the two 
specific include files required for compilation. The processor names that are known to the 
macroprocessor are established in the file named procs.inc. The correspondence between 
the processor name and the subroutine called when the name is encountered in a com- 
mand is established in the file named subcalls. inc. These files are inserted into the Fortran 
source prior to MAX precompilation. Maintaining the processor-specific information in 
the separate include files allows the macroprocessor to be customized for the application 
by changing only the two included files and ret ompiling the main program. 

Languages 

Fortran is the primary language for the Testbed source code. The Testbed architecture 
modules are written in Fortran-77, with extensive use of character variables, and a small 
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amount of assembler and C code in the low-level I/O modules for the data management 
functions. The application modules are written in both Fortran-66 and Fortran-77, the 
combination of which has presented some limitations to naming conventions for data base 
entities and processors because of the old code used as a core analysis capability. However, 
the flexibility of the supporting NICE modules is maintained for use by new application 
modules. 

Procedures for Building 

Procedures and scripts for preprocessing, compiling, and linking the Testbed have been 
developed for the target systems. The scripts on all the UNIX-type systems are almost 
identical, with differences in the keys used for MAX precompilation, the name and options 
for the Fortran compiler to be used, and the name and options for the loader program to 
be used. A set of “makefiles” is used, with a top-level “make” invoking lower-level “makes” 
to create the required object files and libraries in the correct order. The procedures for 
building the code under a VMS™ operating system are similar in organization but are 
implemented in the DCL command language without all the power and flexibility of the 
UNIX make utility. 

VERIFICATION PROCEDURES 

In order to verify the correct installation of the Testbed code, programs which test the 
operation of the programmer interface with the command language interpreter and with 
the data manager are built on the target computer and executed after the object libraries 
for that software have been created. Correct results (manually verified at present) from 
executing these programs verify the installation of the command language and data man- 
ager. Once this successful installation has been established, the macroprocessor is built 
and the scripts for the demonstration problems may be executed. These scripts are written 
in CLAMP, which is portable across all the different computer systems where the Testbed 
has been installed. System dependent commands such as those for deleting files, redirect- 
ing input and output, and invoking execution of the Testbed are the only differences in 
the text of the demonstration problem scripts. These scripts also serve the purpose of 
providing a variety of examples of Testbed usage for new users. 


10 



CRAY-2 IMPLEMENTATION 


Installation of the Testbed on the NAS CRAY-2 computer was accomplished over a period 
of about one month in 1987 shortly after thi; computer was made available to NASA 
Langley users. The Testbed code was the largest software system to be ported to the NAS 
computer, and consequently many problems which had not been experienced by other 
users had to be diagnosed and overcome. 

The first step of the installation, which had to be performed before any compilation could 
be done, was to build the MAX and INCLUDE utilities under UNICOS. This required 
writing an interface between the Fortran program and the C language argc and getarg 
functions not provided in the Fortran libraries. Next, compilation of the NICE software 
was accomplished and object libraries created. The test programs for the NICE software 
were built and executed successfully. Then the macroprocessor, application modules, and 
utility routines were compiled. Finally, the linking of the executable file was performed. 
Compilation Problems 

Because the Testbed Fortran code uses character variables heavily, the CFT77™ compiler 
had to be used for compilation. Most problems encountered with this compiler were related 
to its handling of character variables and formatting screen and printed output and were 
not encountered until execution time. Most of these were resolved by inserting code blocks 
for the CRAY/UNICOS version into the master source files so that the modifications 
could be carried along into future versions of the code. The porting of the Testbed to the 
CRAY-2 was accomplished using a very early version of CFT77 under UNICOS. Although 
several compiler errors were discovered with that compiler, no errors that could not be 
easily avoided were uncovered. The compiler errors that were discovered have been fixed 
in subsequent releases of the CFT77 compiler. 

Fortran /C Interface 

One problem related to CFT77 character handling which had to be resolved twice was 
the difference in data structures for CFT77 character arguments and C compiler character 
string arguments. This problem arises where the Fortran code for the data management 
functions calls low-level C language I/O functions. The CFT77 compiler does not conform 
to the same standard as the Fortran compilers on other UNIX-type systems. To overcome 
the problem, a C structure was defined in the C functions to correspond to the CFT77 
character argument; upon entry to the C function, a transformation was performed from 
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the argument structure to a C character string. When version 3.0 of UNICOS was installed 
with a new CFT77 compiler, the CFT77 character variable structure was changed without 
documentation, so the C functions had to be modified to accommodate the new structure 
after the difference was discovered. The definition of the Fortran and C character pointer 
structures under UNICOS 3 are: 


typedef struct { ushort offset: 3; /* string offset in bytes */ 

ushort filerl: 3; /* length ’bits’ count */ 

ushort length: 23; /* string length in bytes */ 

ushort filer2: 3; /* offset ’bits’ count */ 

ushort addres: 32; /* string address */ 

} chptrf ; /* CHar PoinTeR Fortran */ 

typedef struct { ushort offset: 3; /* string offset in bytes */ 

ushort f iler3: 29; /* unused space */ 

ushort addres: 32; /* string address */ 

} chptrc; /* CHar PoinTeR C-lang. */ 


The called C function assigns the offset and address fields of the input Fortran pointer 
to the respective fields of the C pointer before moving the characters to a local character 
array. The use of these structures is illustrated in the block I/O routines in Appendix A. 

Loader Problems 

The initial installation procedures used the LD loader for linking the executable file. When 
the optimization options for the CFT77 compiler had been used in compilation, all sub- 
routine argument addresses and some temporary variables were defined in local memory 
by the compiler. The LD loader concatenates the local memory segments for all modules, 
so attempting to link all of the application modules and libraries in the macroprocessor 
resulted in overflow of local memory (40000 8 words) and failure of the load. The LMSTAK 
utility to enable overlaying local memory segments was used, but the resulting program 
would not execute. In order to check out the operation of the software before resolving the 
local memory overflow problem, all the code was recompiled without optimization, linked 
successfully, and tested. 

Later, following the suggestion by the NAS CRAY analysts, the segmentation loader 
(SEGLDR™) was used. This loader performs the local memory overlay correctly, so 
the optimized object code could be used. No execution errors were encountered as a result 
of using the optimizing compiler. Performance was improved by a factor of 3 in CPU us- 
age with the optimized code for most of the demonstration problems executed. However, 
vectorization is not used efficiently in this version of the code because of the short vector 
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lengths actually used (< 6 in a critical area). Mach greater improvements should be gained 
by tailoring the matrix operations in the code to take advantage of vectorization. 

Installation of a new CFT77 compiler with op tions to enable the user to control the al- 
location of local memory has since eliminated the requirement to use SEGLDR for the 
Testbed to overlay local memory. 

Optimization 

In order to identify the most promising areas for performance improvement, two utili- 
ties were used. First, the FLOW utility was used, after recompilation of the code with 
the CFT77 flowtrace (-ef) option. The resulting executable file was used to run several 
demonstration problems performing different types of analysis functions. The FLOW util- 
ity analyzed the output files and identified the modules which were using most of the CPU 
time for the executions. A calling tree diagram was also obtained in the FLOW output, 
which was helpful in analyzing the execution path of the program. 

After identifying the biggest CPU users, the Fortran source code for those modules was 
sent to an IRIS™ workstation on which the FORGE™ software was installed. FORGE 
was used to insert timing function calls into th< modules which were then sent back to the 
CRAY, compiled and linked into the executable. The demonstration problems were run 
again and very detailed analyses of the execution of the modules of interest were obtained. 
These analyses led to replacement of some code with UNICOS library function calls and 
some other minor revisions. This work resulted in an improvement of about 12% in the 
performance of the affected analyses. 

This installation of the Testbed on the CRAY -2 is allowing researchers to analyze much 
larger problems in a reasonable turnaround time than has been possible with the mini- 
computer installations previously available. 

STRUCTURAL ANALYSIS METHODS DEVELOPMENT EXPERIENCES 
Workstation development of new analysis code and procedures 

Researchers at NASA Langley have been using a distributed computer environment to 
develop new analysis modules and procedures, v/ith each researcher working in the Testbed 
environment on a local computer or workstation of his preference. Procedures, scripts and 
makefiles similar to those for maintaining the complete Testbed system are available to 
the Testbed developers for building external processors or customizing macroprocessors. 
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The researcher has to be concerned only with the code for his new module, calling utility 
subroutines from Testbed libraries, where applicable, and using the interface routines for 
command input and data management functions. There are minimal requirements pre- 
scribed for initialization and termination to ensure compatibility with installed processors. 
Where a new module must interact with other Testbed modules via the data base, it must 
conform to the data structures defined by the existing modules. The new module must 
have a name different from any analysis module installed in the Testbed if it is to be exe- 
cuted within a CLAMP procedure along with Testbed modules. Typically, the module is 
tested on the local workstation or minicomputer to verify its operation before it is sent to 
the CRAY-2 for further testing. 

Once the new module has been initially tested on a local computer, the source code and/or 
procedures are transferred to the NAS CRAY-2 system via a network, and an executable 
file is built on the CRAY using the same procedures as on the local computer. CLAMP 
scripts for verifying the processor operation on the local computer are also portable from 
the local computer to the CRAY-2. 

CRAY-2 UNICOS Environment 

A shell script and makefile used for building an external processor on the CRAY-2 computer 
are shown in Figures 2 and 3. The script refers to an environment variable CSM_ROOT 
which contains the name of the root directory for the Testbed software files. This variable 
is passed to the makefile as a macro variable to be used for defining the names of utility 
object files and library files to be linked with the new module. The makefile uses the MAX 
and INCLUDE utilities and requires that the user have his PATH environment variable 
defined so that those files are accessible. 

A login script is provided for Testbed users to execute to define their environments for 
compatibility with these scripts. The user should determine the pathname for the root 
directory of the Testbed files on each of the computers where the Testbed is to be used. To 
execute the Testbed login script on a particular computer at login time, the user should 
insert the following commands in his “.login” file: 

setenv CSMJtOOT "system_dependent_path" 

source $CSM_R00T/login 
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To precompile, compile, and link a new module into an executable external processor, the 
following command is used: 

bldextp module_name [object_f ile_name j] 

where module_name is the root name of the mod ule source file, which resides in the current 
directory with extension “.ams”; the optional argument, object_file_names, is a list of object 
files to be linked with the module. The script automatically links in the Testbed utilities, 
so these do not have to be included in the list. 

The command to execute the Testbed macroprocessor is: 
testbed 

The user’s PATH environment variable is defined in the login script so that the directory 
in which the Testbed executable resides is searc ied by the shell when the above command 
is entered. 

An example shell script for executing the Testbed in conjunction with an external processor 
is shown in Figure 4. 

FUTURE DIRECTIONS FOR THE CSM TESTBED 

The future directions of the CSM Testbed will be tied to developments in several other 
areas, particularly the evolving computer hardware industry. The changes in computer 
hardware will, out of necessity, result in changes to operating systems and systems software 
in order to take advantage of the changes in hardware. New approaches in applying 
numerical analysis will result from changes in computer hardware and software. This 
evolving technology provides more and faster computer architectures but only at the cost 
of software compatibility and complexity. 

The CSM Testbed is being extended to exploit the multiple instruction multiple data 
(MIMD) computers that are becoming generally available. To support analysis on MIMD 
computers, the command language is being rewritten and advanced numerical algorithms 
are being developed 

Command Language Enhancements 

In order to provide a better Testbed environment, enhancements to the command language 
are being developed. The current command language capability was developed over the 
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course of a decade (ref. 13). The present version of the command language interface 
program (CLIP) contains 129 subroutines and 18,000 lines of source code. 

Enhancements to CLIP are underway to include the implementation of a table driven 
parser and lexical analyzer. The UNIX utilities LEX and YACC will be used to implement 
an easily extendable language. This language will be primarily the CLAMP language 
implemented by Felippa in the NICE computer environment with modifications to remove 
context sensitive constructs from the language. Care is being taken to retain all the 
problem solving capability proven effective over the last decade while adding generality. 
As a side benefit we expect the resulting interpreter to be more efficient and maintainable 
in addition to providing the required extendability. This extendability will be tested by the 
addition of language directives to control processor/task allocation and synchronization at 
a high level through CLAMP directives. The resulting capability will provide a convenient 
research environment for the structural analyst to investigate parallelism without relying 
on computer dependent coding. 

Advanced Numerical Algorithms 

Numerical analysts in the CSM activity are developing many new algorithms designed to 
take advantage of the vector processing capability offered by many modern computers. In 
the past, the sparse nature of the matrices that dominate structural analysis compute 
tions has made vector processors of limited use. Now, however, in addition to numerical 
algorithms for vector computers, CSM researchers are developing algorith ms for MIMD 
computers. Recent research on algorithms for vector and MIMD computers are described 
in references 14, 15, and 16. Work will continue on the development of numerical algo- 
rithms that will take advantage of both the vector capabilities and the MIMD capabilities 
of future computers. 

CONCLUDING REMARKS 

The CSM Testbed is a useful and powerful development environment for developing struc- 
tural analysis and computational methods. The Testbed development environment pro- 
vides the mechanism to allow researchers concentrating on different parts of the structural 
analysis problem to communicate on solutions to problems that directly relate to current 
NASA needs. The transfer of technology among researchers in computer science, numer- 
ical analysis, and structural engineering can now be accomplished more effectively than 
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was previously possible. 

The CRAY-2 provides an extremely powerful 1 op-end capability for performing structural 
analysis applications in a networked distributed environment. It is possible for the same 
Testbed applications runstream to be used on computers ranging from a workstation run- 
ning UNIX through the CRAY-2 supercomputer. A runstream may now be checked out on 
a workstation for a small model prior to performing fullscale calculations on the CRAY-2. 

Since the CSM Testbed was operational in a U NIX environment prior to converting to the 
CRAY-2, the implemention under UNICOS was accomplished without significant prob- 
lems. The Testbed program was made operat ional under a pre-release CFT77 compiler. 
Although several compiler errors were found, corrections were possible with the help of 
the Cray analysts. 

Planned development of the CSM Testbed on supercomputers will involve extensions that 
will allow researchers to develop combined veclor/MIMD applications methods in an inte- 
grated environment. The integrated environment is characterized by a common operating 
system, common file system, and usually a common administrative system. 
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Figure 1. CSM Testbed Organization 


#! /bin/sh 

# 

# Shell script for invoking make to build an external processor executable; 

# Environment variable CSM-ROQT must be defined prior to invoking this script. 


# Usage: bldextp processor -name [other-objects] 

# where: processor-name is the name of the executable file to be built; 

# (the source code for the processor must be in 

# a file of the same root name with extension .ams) 

# other-objects is an optional list of full pathnames of object files 

# to be built and linked with the processor object, 

# Testbed utilities and NICE libraries 

# 

case $# in 

0) echo 'Usage: bldextp processor-name [other-objects]’ 1>&2 ; exit 2;; 

2) EXTP-ll ; shift 

esac 

# 

# Check to make sure shell variables are defined 

# 

case H $CSM_R00T" in 

H ”) echo 'CSM environment variables must be set before invoking bldextp. * 1>&2 
exit 2 

esac 

# 

# make other object files first 

# 

for i in $* 

do 

echo Making $i 
FILE- 1 basename $i .o' 

DIR-'dirname $i* 

( case H $DIR" in 

imj 

*) cd $DIR 
esac 

make -f $CSM-R00T/sara/tbo .mk $FILE.o CSMJ100T«$CSM-R00T \ 

MAXKEYS-"NICE EXTP TEK" ) 
case $? in 
0 ) ;; 

*) exit 2 
esac 
done 

# 

# make external processor object and executable 

# 

echo Making $EXTP 

FILE* ' basename $EXTP* 

DIR-'dirname $EXTP* 

FILE* 'basename $FILE .o' 

( case H $DIR H in 

M M J . . 

*) cd $DIR 
esac 

make -f $CSM_R00T/sam/tbo .mk EXE=$FILE CSMJ100T=$CSMJ100T 0BJS-”$* B \ 
MAXKEYS-«NICE EXTP TEK H ) 

Figure 2. Shell script for building a Testbed external processor 
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# tbo.mk 

§ 

# Makefile for building a Teatbed object or executable file 

# 

# Build an object file for a Testbed module from an AMS file. 

# Link the object files with Testbed utility object files and 

# NICE libraries. 

# 

# Macros (Make macros which may be overridden on the make command) 

# 

# CSMJ100T must be defined on the make command 
CSMJ40D - $(CSM_R00T)/sam/mod 

CSM.UTL - $(CSM_ROOT)/sam/utl 
EXE - testbed 
FC - cft77 

PFLAGS - -a static -ecrsx 
INCDIR - . 

LD - segldr 
LFLAGS - 

MAX KEYS - NICE TEK 
NICELIBS - $(NLB)/clp861b.a \ 

$ (NLB) /gal861b . a \ 

$ (NLB) /dmg861b . a \ 

$ (NLB) /utl861b . a \ 

$ (NLB) /bio861b . a 
NLB - $ (CSM_R00T) /nice/lib 
OBJS - 

UTILS - $(CSM_MOD)/gsutil.o \ 

$ (CSM J40D) /nsutil . o \ 

$(CSMJ40D)/nsparlibl.o \ 

$(CSM_M0D)/nsparlib2.o \ 

$ (CSM _MOD) /nsparlib3 . o \ 

$(CSMJJTL)/plotlO. a 



# Suffix Rules 

# 

.SUFFIXES: 

.SUFFIXES: .aros .o ^ 

# Transform .ams file to .o file; use include and max utilities, then compile 

. ams . o : 

include ~ i $*.ams -o $*.tmp -d $(INCD[R) 

- r m $ * . f 

max /wc/uc/for/sic/ti/mach-unix -i $*.tmp -o $*.f $(MAXKEYS) 

- rm $*.tmp 

$ (FC) $(FFLAGS) $*.f 

# rm $*.f 



# Targets 



# Executable depends on an object file with the same root name ; 

# link with named objects, utilities, and NICE libraries 
$ (EXE) : $ (EXE) . o 

$(LD) $ (LFLAGS) -o $0 $«.o $(0BJS) $(JTILS) $ (NICELIBS) 

Figure 3. Makefile for building a Testbed external processor 
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time testbed << \eof 

♦SET ECHO OFF 

♦open 1 cube. 101 

♦PROCEDURE CUBE 

♦DEF NN -- 7 

♦DEF/g LL -- 22.222222 

♦DEF NNMI -< <NN> - 1> 

♦DEF NNNN -< <NN>^<NN> > 

♦DEF JNT -< <NNNN>*<NN> > 

[XQT TAB 
online-0 

START < JNT> 4,5,6 
[XQT AUS 
online-0 

TABLE (NI-31, N J-l) : PROP BTAB 2 21 
J-l 
.101> 

. lE-6> 

- .3E-7 . lE-6> 

- . 3E-7 - . 3E-7 .lE-6> 

0.0 0.0 0.0 . 26E-6> 

0.0 0.0 0.0 0.0 . 26E-6> 

0.0 0.0 0.0 0.0 0.0 . 26E-6> 

0.0 0.0 0.0> 

1.0 1.0 1.0 1.0 1.0 1.0 
[XqT TAB 
online-0 
JLOC 

♦DEF N - <NN> 

*DEF/i JCNT - 1 
♦DEF/g Z - 0.0 

*DEF/g DELZ -< <LL>/<NNM1> > 

♦DO $1-1, <N> 

<JCNT> 0. 0. <Z> <LL> 0.0 <Z> <NN> 1 <NN> 

<NN> 0. <LL> <Z> <LL> <LL> <Z> 

♦DEF/g Z -< <Z> + <DELZ> > 

♦ DEF/i JCNT -< <NNNN> + <JCNT> > 

♦ENDDO 

MATC : 1 10. +6 .3 .101 

CON 1 : ZERO 1,2,3: 1 : <NN> : <NNNN> 

♦DEF N -< <NNNN> - <NN> + 1 > 

<N> 

[XQT ELD 
online-0 
S81 

1 <NNM1> <NNM1> <NNM1> 1 <NN> <NNNN> 0 1 

[xqt pfmx . Execute external processor pfmx (experimental version of PFM) 
reset method-5 ,maxcon-8 , nalg=0 
[XQT TOPO 

reset maxsub-40000, LRAM-12288 
stop 

♦sho macros 
[xqt dcu 
toe 1 

♦END 

♦CALL CUBE 
[XQT EXIT 
\eof 


Figure 4. Example script executing Testbed with external processor 
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Appendix A. Testbed CRAY-2 Block I/O Routines 


IOXCLO - Close a file 


1 

2 

3 

4 
6 
6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 
26 
26 

27 

28 

29 

30 


42 

43 

44 

45 

46 

47 

48 


IOXCLO: close (/delete) a file from iandon i/o, given it's descriptor 

Modified for UNICOS 3.0 cft77 character arguments 

this routine is called in fortran (f77) via: 

call IOXCLO (fd, opt, path, size, bksz, blks, msg ) 


input arguements: 

fd - file descriptor for file (for closing) 

opt * 1 character close option flag, vhere 

opt - * ' for normal close 

'd* for close/delete option 

path - complete 'path' name of file (for delete opt) 

output arguements: 

size * size of file (in bytes) 

bksz - optimum block size of file 

blks « number of blocks in file 

msg * error return message (blank if no error) 


#include <stdio.h> 
#include <sys/types .h> 
#include <sys/file.h> 
#include <sys/stat.h> 


31 

typedef struct { ushort 

offset : 

3; 

32 

ushort 

f ilerl : 

3; 

33 

ushort 

length: 

23; 

34 

ushort 

f iler2: 

3; 

35 

ushort 

addres : 

32 ;> 

36 




37 

typedef struct { ushort 

offset : 

3; 

38 

ushort 

f iler3 : 

29; 

39 

ushort 

addres : 

32; > 

40 




41 

/******************** 




> chptrf; 


y chptrc; 


* entry - IOXCLO * 

********************/ 

IOXCLO (fd, opt, path, size, bksz, blks, msg) 

chptrf path, opt, msg ; 

long int *fd, *size, *bksz, *blks ; 
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49 




50 

< 



51 




52 


extern int 

errno ; 

53 


extern int 

BLKSIZ ; 

54 




55 


chptrc 

cpath, copt; 

56 


int 

lpath, lopt, lmsg ; 

57 


char 

♦op, *pp, fnam[256] ; 

58 




59 


int 

i; 

60 


struct stat 

stbuf ; 

61 




62 


errno - 0; 

/♦ clear the error code no. ♦/ 

63 




64 


/♦ create local C-pointers form FORTRAN -point ere */ 

65 




66 


cpath. off set 

* path. offset; 

67 


cpath. addres 

- path. addres; 

68 


lpath 

- path. length; 

69 




70 


copt . offset 

- opt. off set; 

71 


copt . addres 

- opt . addres ; 

72 


lopt 

- opt. length; 

73 




74 


Imsg 

« msg. length; 

75 




76 


PP 

* cpath; 

77 


op 

• copt ; 

78 




79 


/* first, extract the file's stats for return ♦/ 

80 




81 


if (fstat(*fd, fcstbuf) -1) /* error in status request ? */ 

82 


< 


83 


♦size * 0; 

/♦ clear file statistics ♦/ 

84 


♦bksz - 0; 


85 


♦blks - 0; 


86 


I0XERR_ (errno, msg, lmsg) ; /* extract error number * 

87 


> 


88 


else 

/♦ valid status info ♦/ 

89 


•c 


90 


♦size - stbuf.st.8ize; /♦ set 'size' « file size (char) 

91 

/* 



92 

* 

*bksz - stbuf . st.blksize ; 

93 

* 

♦blks * stbuf . Bt.blocks ; 

94 

*/ 



95 


IOXERR. (NULL , msg, lmsg ); /* clear error number 

96 


> 


97 




98 


/♦ second, close the file pointed to by 'fd* */ 

99 




100 


if (close(*fd) ~ -1) /* error on close request ? */ 

101 


< 
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102 

I0XERR_ (errno , nag, lmag) ; 

/* extract error number */ 

103 

return; 


104 

> 


105 



106 

/* last, check option and delete 

file if request is on */ 

107 



108 

if (*op — *d') 

/* delete option on ? */ 

109 

i 


110 



111 

/* transfer FORTRAN character string (path) to local array fnam[] 

112 



113 

o 

t 


114 

while ((*pp !- AO’) kk (*pp !■ 

■ ' *)**(!< lpath)) 

115 

< 


116 

fnam[i++] “ *(pp ++ ); 


117 

> 


118 

fnam[i] ■ ’\0’; 


119 



120 

if (unlink(fnam) — -1) 

/* error on delete request ? */ 

121 

{ 


122 

I0X£RR_ (errno, mag, lmag); 

/* extract error number * 

123 

} 


124 

> 


125 

return ; 


126 > 
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IOXERR - Return a system error message, given the error no. 


1 /* IOXERR: return a system error message, given *erno* 

2 * Modified for UNICOS 3.0 cft77 character arguments 

3 * 

4 * IOXERR. (erno , msg, lmsg ) 

6 ♦ 

6 * input arguements: 

7 * 


8 

* 

erno 

- system error number 


9 

♦ 


if erno - 0, NULL error, 

ierr - 

10 

* 


erno < 0, undefined, 

ierr - 

11 

* 


erno > sys.nerr, undefined, 

ierr ■ 

12 

* 

lmsg 

- length of message string ’msg* 


13 

* 




14 

* 

output 

arguements : 


15 

* 




16 

* 

msg 

- error message (blank if ’erno* — 

- NULL ) 

17 

* 




18 

*/ 




19 





20 

# include 

<stdio .h> 


21 

#include 

< errno .h> 


22 






0 

-1 

-1 


23 IOXERR. (erno, msg, lmsg ) 

24 

25 char *msg; 

26 long int erno, lmsg; 

27 

28 { 

29 extern int sys.nerr; /* largest error no. for which system */ 

30 /* system tables has a defined message */ 

31 extern char ♦sys.errlist [] ; /* table of system error messages */ 

32 

33 strncpy ( msg, ” ", lmsg ); 

34 if (erno -■ NULL) /* NULL error message returned */ 

35 { 

36 return ; 

37 > 

38 

39 if (erno>0 Aft erno<sys_nerr) 

40 { 

41 strncpy (msg, sys.errlist [erno] , lmsg ); 

42 printf ( M IOXERR: ierr - %4d (%s)“, errno, sys.errlist [erno] ) ; 

43 > 

44 else 

45 { 

46 strncpy (msg, “ERROR: unknown error value”, lmsg); 

47 printf (” IOXERR: ierr - %4d (unkown error value ?)”, errno); 

48 > 

49 return; 

50 > 
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IOXLOC - Extract the current position within a file 


1 

2 

3 

4 
6 
6 

7 

8 
9 

10 

11 

12 

13 

14 
16 
16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 


IOXLOC: extract the current position within a file 

Modified for UNICOS 3.0 cft77 character arguments 

this routine is called in fortran (f77) via: 

call IOXLOC (fd, size, bksz, blks, pos, mag) 

input arguements: 

fd - file descriptor for file 

output arguements: 

size - size of file (in bytes) 

bksz - optimum block size of file 

blks “ number of blocks in file 

pos - position within file returned by lseek(2) 

msg - error return message (blank if no error) 


#include <stdio . h> 

# include <sys/types .h> 

#include <sys/f ile .h> 

# include <sy s/ stat . h> 


27 

28 

29 

30 

31 

32 

33 

34 
36 

36 

37 

38 

39 

40 

41 

42 


typedef struct { 


ushort offset: 3 
ushort filerl: 3 
ushort length: 23 
ushort filer2: 3 
ushort addres : 32 


> chptrf; 


/* 

* 

* 


the following flags represent file positioning 
parameters used by lseek( ) 


*/ 

#def ine 
#def ine 
#def ine 


L_SET 0 /* absolute offset (from BOF) 
L.INCR 1 /* relative to current offset 
L.XTND 2 /* relative to end of file 


43 IOXLOC (fd, size, bksz, blks, pos, msg ) 

44 

45 chptrf msg; 

46 long int *fd, *size, *bksz, *blks, *pos; 

47 

48 { 

49 

50 int Imsg ; 

51 extern int errno; 


*/ 

*/ 

*/ 


A-5 



52 

extern int BLKSIZ; 

53 

struct stat stbuf ; 

54 


56 

Imsg * msg. length; 

56 


67 

♦pos - lseek (*fd, 0L ( L.INCR) ; 

58 


59 

if (fst&t(*fd, Jtstbuf) « -1) 

60 

{ 

61 

♦size - 0; 

62 

♦bksz * 0; 

63 

♦blks - 0; 

64 

IOXERR_(errno , msg, Imsg); 

65 

> 

66 

else 

67 

< 

68 

♦size * stbuf . at_size ; 

69 /♦ 


70 * 

♦bksz ■ stbuf . st_blksize ; 

71 * 

♦blks - stbuf . st_blocks; 

72 ♦/ 


73 

I0XERR_ (NULL , msg, Imsg ); 

74 

> 

75 

return ; 

76 } 



/♦ extract position within file */ 

/* error in status request ? */ 

/* clear file statistics */ 

/* extract error number ♦/ 

/* valid status info ♦/ 

/* set 'size* * file size (char) ♦/ 

/* clear error number ♦/ 
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IOXOPN - Open a file for random I/O 


1 

/* 

IOXOPE 

open a file for randon i/o t given it’s path name 

2 

* 

Modified for UNICOS 3.0 cft77 character arguments 


3 

4 

♦ 

* 

this routine is called in fortran (f 77/ via: 


6 

6 

* 

* 

call IOXOPE (path, opt, fd, size bksz, lbka, mag ) 

7 

8 
9 

* 

* 

* 

input arguements: 


10 

* 




11 

* 

path 

- complete 'path* name of fil*> 


12 

* 

opt 

- 2 character open option flafjs, where 


13 

* 


opt [0] - *r ’ for * read-only ‘ 


14 

* 


*w' for *write_appfmd* 


15 

♦ 


• ' for both 'read. write* 


16 

* 


opt[l] - *o' for 'existing' file open 


17 

* 


*n* for *create_new* file open 


18 

* 


*s' for 'scratch* file open 


19 

* 


* * for 'create_new # even if file 


20 

* 


already exists (truncate old) 


21 

♦ 




22 

* 

output 

arguements: 


23 

* 




24 

* 

fd 

- file descriptor for open file 


25 

* 

size 

- size of file (in bytes) 


26 

* 

bksz 

■ optimum block size of file 


27 

* 

blks 

- number of blocks in file 


28 

* 

msg 

* error return message (blank if no error) 


29 

* 




30 

*/ 




31 





32 

#include 

<stdio .h> 


33 

#include 

<sys/types .h> 


34 

#include 

<sys/f ile .h> 


35 

# include 

<sys/stat .h> 


36 

#include 

<errno .h> 


37 





38 

#include 

<f cntl . h> 


39 

/* 




40 

* 

the following flags represent file 


41 

* 

accessing modes used by open( ) 


42 

* 




43 

*/ 




44 

#def ine 

R_0K 04 /* read permission 

*/ 

45 

#def ine 

W_0K 02 /* write permission 

*/ 

46 

#def ine 

X_0K 01 /♦ execute/seacch permission 

*/ 

47 

#def ine 

F_0K 00 /* file existence 

*/ 

48 





49 

int 

BLKSIZ - 4096; /* preset block/buffer eize 


50 



in bytes ( « 512 words) 

*/ 


si 
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62 

typedef struct 

{ uahort offset; 3 

/* string offset in bytes */ 

63 


ushort filerl: 3 

/* length 'bits* count */ 

54 


ushort length: 23 

/* string length in bytes */ 

55 


ushort filer2: 3 

/* offset 'bits’ count */ 

56 


ushort addres: 32 

/* string address */ 

57 


> chptrf ; 

/* CHar PoinTeR Fortran */ 

58 



/* */ 

59 




60 

typedef struct 

{ ushort offset: 3 

/* string offset in bytes */ 

61 


ushort filer3: 29 

/* unused space */ 

62 


ushort addres: 32 

/* string address */ 

63 


} chptrc ; 

/* CHar PoinTeR C-lang. */ 

64 



/* */ 


Q5 /ft********************* 

66 * entry - IOXOPE * 

67 **********************/ 

68 

69 IOXOPE (path, opt, fd, size, bksz, blka, msg ) 

70 

71 


72 

chptrf path, 

opt, msg ; 

73 

long int *fd, 

♦size, *bksz, *blks ; 

74 



75 

< 


76 



77 

extern int 

errno ; 

78 

extern int 

BLKSIZ; 

79 



80 

chptrc 

cpath, copt; 

81 

int 

lpath, lopt, lmsg; 

82 

char 

oc, *op, *pp, fnam[256] ; 

83 



84 

int 

i, flags, mode, acc; 

85 

struct stat 

atbuf ; 

86 



87 

/* create local C-pointers form FORTRAN-pointers */ 

88 



89 

cpath. offset 

* path. offset; 

90 

cpath. addres 

* path. addres; 

91 

lpath 

- path. length; 

92 



93 

copt . offset 

* opt. off set; 

94 

copt . addres 

* opt. addres; 4 

95 

lopt 

* opt. length; 

96 



97 

lmsg 

- msg. length; 

98 



99 

PP 

- cpath; 

100 

op 

“ copt ; 

101 



102 

/* transfer FORTRAN character string (path) to local array fnam[] */ 

103 



104 

i - 0; 
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105 

while (C*pp !- *\0*) 

kk (*pp ! 

- ’ il (i < lpath)) 

106 

{ 



107 

fnam[i++] ■ *(pp+ + ) 

1 


108 

> 



109 

fnam[i] - '\0'; 



110 




111 

/* setup open options by checking file status */ 

112 




113 

o 

o 

N 

n 


/* set open/create flag - 'create' */ 

114 

acc - access(fnam. 

F_0K) ; 

/* attempt to access the file */ 

115 




116 

if (acc — -1) 


/* file does not exist */ 

117 

< 


/* . — — — — - */ 

118 

if (*(op+l) — 'o') 


/* user option says 'old' */ 

119 

i 



120 

I0XERR_ (errno , mag, lmsg ); /* extract error number */ 

121 

return ; 


/* 3 eturn to user */ 

122 

> 



123 

> 



124 

else 


/* iile exists */ 

125 

< 


/* — */ 

126 

if (*(op+l)-«’n’) 


/* user option says 'new' */ 

127 

oc - 'c' ; 


/* set open/create flag - 'create' */ 

128 

else 


/* user option says ' old/both * */ 

129 

oc * O , 


/* net open/create flag * 'open' */ 

130 

> 



131 




132 

mode * 0644 ; 


/* net protection ■ (r\r_,r ,r — ) */ 

133 




134 

flags * 0; 


/* net open 'flags' using (opt) */ 

135 




136 

if (*(op) — 'r') 

flags - 

flags I O.RDONLY; 

137 

if (*(op) — ’w‘) 

flags - 

flags | O.WRONLY; 

138 

if (*(op) -- * •) 

flags - 

flags | OJtDWR; 

139 




140 /* 

if (*(op+l) — *o’) 

flags - 

flags | 0_EXCL; */ 

141 

if (*(op+l) -- *n') 

flags - 

flags I 0_CREAT 1 O.TRUNC; 

142 

if (*(op+l) -- ’a’) 

flags - 

flags I O.CREAT 1 O.TRUNC; 

143 




144 




145 

♦size * 0; 


/* net defaults for file size */ 

146 

♦bksz - 0; 



147 

*blks - 0; 



148 




149 

*fd - open(fnam, flags, mode); /* open/create file 'path' */ 

150 




151 




152 

if (*fd -- -1) 


/* *rror on open/create request */ 

153 

{ 



154 

I0XERR_ (errno, msg, 

lmsg ) ; 

/* extract error number 

165 

> 



156 

else 


/* valid file open, check status */ 

157 

< 
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158 if (fBtat(*fd, tstbuf) — -1) /* error in status request ? */ 

150 < 

160 IOXERR_ (errno , msg, lmsg ); /* extract error number */ 

161 > 

162 else /* valid status info */ 

163 { 

164 *size - stbuf . st.size; /* set 'size' - file size (char) */ 

165 /* 

166 * *bksz - stbuf . st_ blksize; 

167 * ♦bike - stbuf . st.blocks ; 

168 */ 

169 IOXERR_(NULL, msg, lmsg ); /* clear error number */ 

170 

171 /* if file has been successfully opened and it is a scratch file, 

172 ** then if the file is unlinked at this point (while still open), 

173 ** it will be deleted when it is closed. 

174 */ 

175 if ( (* (op+l) — ’s') kk (unlink(fnam) !- 0)) 

176 I0XERR_ (errno, msg, lmsg) ; 

177 

178 > 

179 > 

180 return; 

181 > 
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IOXRDR - Read n words from file 


1 /* IOXRDR: read ’n* words from file *fd , starting at block no. *blk* 

2 * Modified for UNICOS 3.0 cft77 character arguments 

3 * 

4 * this routine is called in fortran (f77) via: 

5 * 

6 * call IOXRDR (fd, buf , nwds, blk msg ) 

7 * 

8 * 

9 * input arguements: 

10 * 

11 * fd - file descriptor for file 

12 * buf - pointer to buffer string (< bar) 

13 * nwds - number of words (long int) to read in 

14 * blk ■ starting ’block* number in file 

15 * 

16 * output arguements: 

17 * 

18 * msg ■ error return message (blank if no error) 

19 * 

20 */ 

21 

22 #include <stdio.h> 

23 tinclude <sys/types .h> 

24 #include <sys/file.h> 

25 

26 typedef struct { ushort offset: 3; 

27 ushort filerl: 3; 

28 ushort length: 23; 

29 ushort filer2: 3; 

30 ushort addres: 32;} chptrf; 

31 /* 

32 * the following flags represent file positioning 

33 * parameters used by lseek( ) 

34 * 

35 ♦/ 

36 #def ine L.SET 0 /* absolute offset (from BOF) */ 

37 #def ine L.INCR 1 /* relative to current offset */ 

38 #define L.XTND 2 /* relative to end of file */ 

39 

40 IOXRDR (fd, buf, nwds, blk, msg ) 

41 

42 chptrf msg; 

43 

44 char *buf ; 

45 long int *fd, *nwds, *blk; 

46 

47 { 

48 

49 extern int errno; 

50 extern int BLKSIZ; 

61 int nbuf, pos, ibuf , lmsg; 


A-ll 



long int offset ; 


52 

53 

54 

55 

56 

57 

58 
69 
60 
61 
62 

63 

64 
66 
66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 > 


lmsg - mag. length; 


nbuf - *nwds * 8; /* 

offset - BLKSIZ * (*blk - 1); /* 

if (offset >- 0) /* 

pos - lseek(*fd, offset, L_SET) 

if (pos — -1) /* 


< 

I0XERR_ (errno , msg, lmsg ); 
return; 

} 

> 

ibuf » read(*fd, buf , nbuf); /* 

if ((ibuf — *1) || (ibuf !■ nbuf)) 

{ 

I0XERR_ (errno, msg, lmsg); 

> 

else 

{ 

IOXERR. (NULL , msg, lmsg ); 

} 

return ; 


no.bytes • 8 * no.words */ 
(byte_wise) offset of ’blk’ */ 

position file before read request */ 

error condition in lseek call */ 

/♦ extract error number 

read in f nbuf* bytes to 'buf 1 */ 

/* error condition on read */ 

/♦ extract error number */ 

/* clear error number */ 


IOXWTR - Write n words to a file 


1 /* IOXWTR: writ© *n* words to file 'fd* t starting at block no. ’blk’ 

2 * Modified for UNICOS 3.0 cft77 character arguments 

3 * 

4 * this routine is called in fortran (f77, via: 

5 * 

6 * call IOXWTR (fd, buf, nwds, blk, msg) 

7 * 

8 * 

9 * input arguements: 

10 * 

11 * fd - file descriptor for file 

12 * buf - pointer to buffer string (long int) 

13 * nwds * number of words (long int) to write out 

14 * blk - starting ’block* number in file 

15 * 

16 * output arguements: 

17 * 

18 * meg - error return message (blank if no error) 

19 * 

20 */ 

21 

22 #include <stdio.h> 

23 # include <sys/types .h> 

24 #include <sys/file.h> 

25 

26 typedef struct { ushort offset: 3; 

27 ushort filerl: 3; 

28 ushort length: 23; 

29 ushort filer2: 3; 

30 ushort addres: 32;} chptrf; 

31 

32 /* 

33 * the following flags represent file pasitioning 

34 * parameters used by lseek( ) 

35 * 

36 */ 

37 idefine L_SET 0 /* absolute offset (from BOF) */ 

38 #def ine L_INCR 1 /* relative to current offset */ 

39 #def ine L.XTND 2 /* relative to end of file */ 

40 

41 IOXWTR (fd, buf, nwds, blk, msg) 

42 

43 chptrf msg; 

44 char *buf ; 

45 long int *fd, *nwds, *blk; 

46 

47 { 

48 

49 extern int errno; 

50 extern int BLKSIZ; 

61 int nbuf, pos, ibuf , lmsg; 
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offset ; 


52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 > 


long int 
lmsg - msg. length; 


nbuf - *nwds * 8; / 

offset - BLKSIZ * (♦blk - 1); / 

if (offset >* 0) /■ 

{ 

pos - lseek(*fd, offset, L_SET) ; 
if (pos — -1) /i 


< 

IOXERR. (errno , msg, lmsg ); 
return; 

> 

} 

ibuf - write(*fd, buf , nbuf); / 

if ((ibuf »» -1) || (ibuf !» nbuf)) 

{ 

IOXERR. (errno, msg, lmsg ); 

> 

else 

{ 

IOXERR. (NULL , msg, lmsg ); 

> 

return ; 


no_bytes » 8 * no.words */ 
(byte_wise) offset of ’blk’ */ 

position file before write request */ 

error condition in Iseek call ? */ 

/♦ extract error number */ 

write in 'nbuf* bytes to *buf* */ 

/* error condition on write */ 

/* extract error number */ 

/* clear error number */ 
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Appendix B. Testbed Main Program 


Testbed Main Program in AMS format 

1 C$Header: nicespar . ams, v 1.3. 1.1 87/09/21 14:59:54 ns Exp $ 

2 C-DECK TESTBED TESTBED FORTRAN 

3 OBLOCK FORTRAN 

4 program testbed 

5 c 

6 c main program for CSM Testbed macroproce^sor 

7 c 

8 C+ + 

9C+ COMMON A GLOB ALS + 

10 c+ + 

11 include 'CSM_INC:KQRCOMA. INC* 

12 common /iando/ iin, ioutx 

13 common/nsextp/iextp 

14 C+ + 

15 C+ LOCALS ♦ 

16 C+ + 

17 character*60 verid , vertitl 

18 character*32 idproc, commnd, cclval 

19 character*64 procnam, filnam, cclmac 

20 character*256 image 

21 character*8 cdt(2) 

22 logical exiB 

23 integer runmod 

24 

25 C+ + 

26 C+ Installed Processors + 

27 C+ + 

28 include 'procs.inc* 

29 C+ + 

30 C+ DATA + 

31 C+ + 

32 data iextp/1/ 

33 data vertitl/ ’ CSM TESTBED Ver. 1.2 - May 1988’/ 

34 C+ + 

36 C+ LOGIC + 

36 C+ 

37 C 

38 C Initialize common variable to the length of the blank common work array 

39 C 

40 kort - kszzz ! Changed from DATA statement CGL 4/86 

41 C 

42 C Send empty message to CLIP to force it to boot 

43 C 

44 call clputC* ') 

45 C 

46 C Set unit where printed output will be written 

47 C Look for macrosymbol 'ns.prtunt* first, then CLIP PRT if not defined 

48 C 
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49 call nsprtu( ioutx, ierr) 

50 C 

51 C-IF VAX 

52 verid- ’VAX/VMS '//vertitl 

53 C-ELSEIF UNIX 

54 verid- ’UNIX '//vertitl 

55 C-ELSEIF CRAY 

56 verid- 'CRAY- 2 ’//vertitl 

57 C-ENDIF 

58 C 

59 C Get current date and time 

60 C 

61 call datimc ( ’R’, o, cdt ) 

62 write (ioutx, ’ (/lx, a, 10x,a, lx, a/) ’) verid, cdt(l), cdt (2) 

63 c 

64 call timrb 

65 call gmacro(l) 

66 c 

67 100 continue 

68 idproc - ’CSM’ 

69 call gmsign( idproc) 

70 200 continue 

71 c 

72 C Get next user command 

73 C 

74 call clnext ( 1 CSM>’,’ Enter command to execute processor: [XQT * 

75 $ //’proc_name' , nitems ) 

76 commnd - cclval(l) 

77 idproc - cclval(2) 

78 C-IF UNIX 

79 lenc - lenetb (commnd) 

80 call cc2uc( commnd, commnd, lenc ) 

81 lenp - lenetb (idproc) 

82 call cc2uc( idproc, idproc, lenp ) 

83 C-ENDIF UNIX 

84 c 

85 c check macrosymbol to see whether or not to initialize blank 

86 c common array to zero 

87 c 

88 initcom-iclmac ( ’ NS_INITCOM ’ ) 

89 c 

90 if( nitems .gt . 1 . and. ((commnd. eq. ’ [XQT') . or . (commnd. eq. ’RUN ’))) 

91 $then 

92 if (idproc .eq. 'EXIT') then 

93 call clput ( ’ *stop’) 

94 else 

95 if( idproc. ne. ’ ’) then 

96 do 300 i-l,nproc 

97 if( idproc .eq. namep(i)) then 

98 if (initcom .ne. 0) then 

99 do 290 j-l,kort 

100 290 a(j)«0. 

101 endif 
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102 


iproc - i 


103 


go to 1000 


104 


endif 


105 

300 

continue 


106 

OIF 

VAX 


107 


procnam- ’ns$extp : ' // idproc// * . exe 1 


108 


call stripbl (procnam) 


109 


inquire (f ile-procnam p exist-ex is) 


110 

OELSEIF UNIX 


111 

c 



112 

c Close bulk output file 


113 

c 



114 


if ( ioutx.ne.6) close ( unit*ioutx ) 


115 

c 



116 

c Convert filename to lower case 


117 

c 



118 


call cc21c (idproc , idproc , lenp) 


119 


procnam-idproc 


120 


exis«. true . 


121 

C 

Let Superclip try to find the file 


122 

C-ELSE 


123 


procnam-idproc 


124 


exis- . true . 


125 

C 

Let Superclip try to find the file 


126 

C-ENDIF 


127 


if(exis) then 


128 

C 



129 

c 

run external processor 


130 

C 



131 


call clput('*run '//procnam i 


132 

C 



133 

C 

If we get back here, there was an error; 


134 

c 

continue if interactive or terminate if batch 


135 

c 



136 


write (ioutx , *) 'Unable to execute * .procnam 

137 


call fbi(runmod) 


138 

302 

if (runmod. eq.0) call endrun ( *CSM' t 302 ) 

139 


go to 100 


140 


else 


141 


write(I0UTX,31O) procnam 


142 

310 

format (* Unable to run *,a, ; File not 

found. * ) 

143 


endif 


144 

C 



145 


else 


146 


write (IOUTX, 320) 


147 

320 

format (' Error, invalid TESTBLD command; 

image follows: *) 

148 


call clglim ( image ) 


149 


write (IOUTX, 321) image 


150 

321 

format (al32) 


151 


endif 


152 


endif 


153 


else 


154 


write (IOUTX, 320) 
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165 

156 

157 

158 

159 

160 
161 
162 

163 

164 

165 

166 
167 


call clglim ( image ) 
write (IOUTX, 321) image 
endif 
go to 100 
1000 continue 
c 

c execute the appropriate processor 
c 

include 'subcalls . inc ' 

1500 continue 
go to 100 
end 

OEND FORTRAN 


B-4 



Include File Containing Processor Abbreviations - (procs.inc) 


1 

2 

3 

4 

5 

6 
7 


parameter (nproc -39) 
character *6 namep (nproc) 

data namep/ ’ AUS’ . ’DCU’ . 'DR’ , ’E’ , ’EIG’ , ’EKS" , 'ELD' , 'EQNF' , 'GSF * , 

$ •INV , 1 , K\ , KG\ , M\ , PS\ , PLTA\ , PSF\ , SSOL\ , TAB\ 

$ 'TOPO' , ’VPRT' , ’VEC’ . ’IMP* . ’PAMA’ . *PKMA’ . 'PRTE* , ’LAU’ , 

$ ‘CSN1 ’ , ’ RSEQ ’ , ’PFM’ , ’MTP’ . ’ 8STA * . 'TAFP’ , * TGEO * , 'TRTA' . 

$ • TRTB • . ’TRTG * , 1 TAK ’ , ’ TADS 1 , 'VIEW*/ 
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Include File for Macroprocessor Subroutine Calls - (subcalls.inc) 

X go to ( 1001 , 1002 , 1003 , 1004 , 1005 , 1006 1 1007 , 1008 , 1009 , 1010 ,1011, 1012 , 

2 $ 1013 , 1014 , 1015 , 1016 , 1017 , 1018 , 1019 , 1020, 1021 , 1022 , 1023 , 1024 , 

3 t 1025 , 1026 , 1027 , 1028 , 1029 , 1030 , 1031 , 1032 , 1033 , 1034 , 1035 , 1036 , 

4 $ 1037,1038,1039) 

5 t , iproc 

6 1001 call AUS 

7 go to 200 

8 1002 call DCU 

9 go to 200 

10 1003 call DR 

11 go to 200 

12 1004 call E 

13 go to 200 

14 1005 call EIG 

15 go to 200 

16 1006 call EKS 

17 go to 200 

18 1007 call ELD 

19 go to 200 

20 1008 call EQNF 

21 go to 200 

22 1009 call GSF 

23 go to 200 

24 1010 call INV 

25 go to 200 

26 1011 call K 

27 go to 200 

28 1012 call KG 

29 go to 200 

30 1013 call M 

31 go to 200 

32 1014 call PS 

33 go to 200 

34 1015 call PLTA 

35 go to 200 

36 1016 call PSF 

37 go to 200 

38 1017 call SSOL 

39 go to 200 

40 1018 call TAB 

41 go to 200 

42 1019 call TOPO 

43 go to 200 

44 1020 call VPRT 

45 go to 200 

46 1021 call VEC 

47 go to 200 

48 1022 call IMP 

49 go to 200 

50 1023 call PAMA 

51 go to 200 
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52 

1024 call PKMA 

53 

go to 200 

54 

1025 call PRTE 

55 

go to 200 

56 

1026 call LAU 

57 

go to 200 

58 

1027 call CSM1 

59 

go to 200 

60 

1028 call RSEQ 

61 

go to 200 

62 

1029 call PFM 

63 

go to 200 

64 

1030 call MPMTP 

65 

go to 200 

66 

1031 call MPSSTA 

67 

go to 200 

68 

1032 call MPTAFP 

69 

go to 200 

70 

1033 call MPTGEO 

71 

go to 200 

72 

1034 call MPTRTA 

73 

go to 200 

74 

1035 call MPTRTB 

75 

go to 200 

76 

1036 call MPTRTG 

77 

go to 200 

78 

1037 call MPTAK 

79 

go to 200 

80 

1038 call MPTADS 

81 

go to 200 

82 

1039 call MPVIEV 

83 

go to 200 
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